home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 605 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.5 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Sun, 07 Jan 96 15:33:47 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: Amiga programmers in deep shit...
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.44q7@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 07 Jan 96 Stephan Schaem wrote to All:
  14.  
  15.  >> You make it sound like that is impossible, while it really isn't given
  16.  >> the right situation:
  17.  
  18.  >>  - Game leaves about 10-20% CPU time free.
  19.  
  20.  SS>  per frame, yes.
  21.  
  22. Of course :-)
  23.  
  24.  >>  - Use small Read()'s and Write()'s (experiment; there is no rush to
  25.  >>  load the level-data right?  It will be faster than floppy's even
  26.  >>  if you use 512-byte read/writes :-))
  27.  
  28.  SS>  I dont mind reading 512k byte at a time... My guess is that even
  29.  SS>  if the device has the data cached it will be too slow. so imagine
  30.  SS>  when it will read a next full block from the HW device. On dataflyer
  31.  SS>  and such controler the game would shudder.
  32.  
  33. Okay, just for you I wrote a test-program to prove it is possible.  Right now a
  34. test-program is running which reads 512 bytes from my IDE drive every VBlank. 
  35. According to Spy the TOTAL CPU time used by my system right now is between 11
  36. and 14% (I've got a 68030/22).  This time is distributed among the following
  37. tasks like this:
  38.  
  39.  SoftSCSI_ATEA.device   2.8%
  40.  DH1                    2.6%
  41.  DoLotsOfSmallReads     1.5%
  42.  DisplaySpy             1.2%  (the program displaying a CPU-time graph)
  43.  input.device           1.1%
  44.  TopCPU                 0.5%  (the program which displayed these values)
  45.  BOOT:C/SMouse          0.3%  (my wb-titlebar clock program)
  46.  
  47. Only the first 3 are the ones involved with reading the data from the HD (the
  48. SCSI-device, the filesystem and the program performing the reads).
  49.  
  50. The DoLotsOfSmallReads program consists of nothing more than this:
  51.  
  52.   do {
  53.     WaitTOF();
  54.     Read(fh,&buffer,512);
  55.   } while(result==512)
  56.  
  57. (I wrote it in ASM so the code above may not be correct :-) I used ASM because
  58. I had to do several tests, and I don't want to wait 2 minutes for every
  59. re-compile :-))
  60.  
  61. My Blanker running at Pri -120 sees no negative influence at all and it runs as
  62. smooth as ever.
  63.  
  64. Note that -normally- when I use my IDE drive EVERYTHING grinds to a halt, if I
  65. remove the WaitTOF() call then my IDE drive will eat all CPU time.
  66.  
  67. Okay, here are some more results (CPU time used under the same circumstances as
  68. above):
  69.  
  70.   controller                | 512 bytes/frame | 4096 bytes/frame
  71.  ----------------------------------------------------------------
  72.  SCSI (gvpscsi.device, DMA) |     15-17%      |     17-18%
  73.  IDE (oktagon IDE)          |     11-14%      |     22-26%
  74.  ----------------------------------------------------------------
  75.  
  76. You can see that a DMA controller really makes a difference but that in general
  77. you shouldn't have to worry about even non-DMA controllers taking too much CPU
  78. time if you keep the block size small enough.
  79.  
  80. If you use block sizes somewhere between 512 and 4096 bytes I think you'll get
  81. very nice reading speeds without noticing a thing.
  82.  
  83.   Throughput speeds (untested):
  84.  
  85.   512 bytes/frame =  25K/s
  86.  4096 bytes/frame = 200K/s
  87.  
  88.  >> This should work even on non-DMA controllers.  Of course the game should
  89.  >> be multitasking, run at a pri less than 5 or so and generally 'behave'. 
  90.  >> Current games hardly fit this description but that doesn't make 'smooth'
  91.  >> HD access impossible.
  92.  
  93.  SS>  If one can read 512byte continously in ~25 raster using read() on a
  94.  SS>  non dma controler , I would say yes too. triple bufffer could 'smooth'
  95.  SS>  the possible sporatic behaviour of the read()/device/HW.
  96.  
  97. Well, see above :-)
  98.  
  99.  SS>  I dont think I want to try that anyway :) You have an HD? you must
  100.  SS> have
  101.  SS>  1extra meg compare to the floppy user, let me preload...
  102.  SS>  If this can work on HD, you could reserve space to decompress an audio
  103.  SS>  mpeg file and play it back during the game... An example for game
  104.  SS>  designed only for HD user. VS floppy & HD
  105.  
  106. As you can see above it ain't really necessary, if you can spare a bit of CPU
  107. time.  Even with 1K or 2K block reads every frame you still beat floppies by a
  108. long way, and without any noticeable slow-downs.
  109.  
  110. Grtz John
  111.  
  112. -----------------------------------------------------------------------
  113.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  114. -----------------------------------------------------------------------
  115. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  116.